PCT/EiP B 9 / 0 6 3 7 7 



EuropaiscK 
Patentamt 



European*^*^ - < 



Europear. ^.^ 
Patent Office 



Office europeen 
des brevetSL 




Bescheinigung Certificate 



Attestation 



Die angehefteten Unterla- 
gen stimmen mit der 
ursprunglich eingereichten 
Fassung der auf dem nach- 
sten Blatt bezeichneten 
europatschen Patentanmel- 
dung uberein. 



The attached documents Les documents fixes a 
are exact copies of the cette attestation sont 
European patent application conformes a la version 
described on the following initialement deposee de 
page, as originally filed. la demande de brevet 

europeen specifiee a la 
page suivante. 



Patentanmeldung Nr. Patent application No. Demande de brevet n*" 

98250315.3 



PRIORITY 
DOCUMENT 

SUBMITTED OR TRANSMITTED IN 
COMPLIANCE WITH RULE 17.1(a) OR (b) 




LA HAYE,LE 

EPA/EPO/OE8 Form 1014 - 02.91 



THIS PAGE BLANK mm 



Blatt 2 der Bescheinigung 
Sheet 2 of the certificate 
Page 2 de i 'attestation 



Europaische^ European Office europeen 

Patentamt Patent Office des brevets 



Anmeldung Nr.: Anmeldetag: 

Application no.: 98250315.3 Date of filing: 07/09/98 

Demande n*: Date de depot: 

Anmelder: 

Applicant(s): 

Demandeur(s): 

DEUTSCHE THOMSON-BRANDT GMBH 
78048 Vmingen-Schwenn1ngen 
GERMANY 



Bezeichnung der Erfindung: 
Title of the invention: 
litre de I'invention: 

Method for addressing a bitstream recording 



In Anspruch genommene Prioriat(en) / Priority(ies) claimed / Priorite(s} revendiquee(s) 



Staat 
State: 
Pays: 



Tag: 
Date: 
Date: 



Aktenzeichen: 
File no. 

Numero de depot: 



Internationale Patentklassifikation: 
International Patent classification: 
Classification Internationale des brevets: 

/ 



Am Anmeldetag benannte Verlragstaaten: 

Contracting states designated at date of filing; AT/BE/CH/CY/DE/DK/ES/FI/FR/GB/GR/IE/IT/LI/LU/MC/NL>1»T/SE 
Etats contractants designes lors du depot: 

Bemerkungen: 

Remarks: 

Remarques: 



EPA/EPO/OEB Form 1012 - 04.98 



THIS PAGE BUNK (USPTO) 



1 Introduction of Stream Recording Format 



1.1 Purpose of the Specification 

This DVD Stream Recording Specification is defined to use rewritable DVD discs for 
recording existing digital bitstreams, editing them and playing them back as bitstreams. 
The Specification is designed to satisfy the following requirements: 

1.1.1 Service Requirements 

LLl.l Individual Pac/cet Size Support 

Any packet size should be supported as long as it is less than 2kByte and of constant 
length within a take. 

Timing Regeneration 

^Pning mechanism (time stamp) needs to be added to every broadcast packet to enable 
proper packet delivery during playback. 

J.LL3 Non-real'time recording/download 

To enlarge the fields of applications, non-real-time recording should be possible. 
However, in this case the STB has to generate the Time Stamp information. 

1^LL4 Data allocation strategy 

Data allocation strategy and file system need to be designed to support real-time stream 
recording. The solution, which will be specified in the RTRW activity, should be studied 
and adopted as close as possible. 

h L h S TOC and Service Information Support 

Many digital services require Service Information which normally is embedded in the real- 
time stream. To support the STB, DVD should provide additional space, which can be 
^sd by the STB to duplicate part of the service information and to add additional TOC 
iwBrmation. 

1,1.1.6 Copy Protection Support 

The Copy Protection rules are discussed in CPTWG and WG9. These rules must be 
supported. In addition any scrambling performed by the service provider or the STB must 
be kept unchanged. In a later stage some joint discussion with SW owners and service 
providers might be needed. 

1.1.2 User Requirements 

User requirements can be grouped into requirements for recording, requirements for 
playback, and requirements for editing. 

(Requirements for Recording) 
1.1.2,1 Real-time Recording 

The format should be designed to enable real-time recording of digital streams. It also 
should allow the user to concatenate recordings, even if those recordings consist of 
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different stream formats. If recordings are concatenated, a (close to) seamless playback 
possibility would be nice but is not required. 

L L 2. 2 Total Recording Time 

Regarding the recording time, the conditions are very similar to the RTRW scenario. 
Therefore the same rules should be valid. In any case the user must be able to 
understand the situation and to take appropriate action, if needed. 

LI. 2^3 Navigation Support 

To support navigation two pieces of information (lists) should be generated during 
recording. 

An 'original' version of a play list . This list contains quite low level information, e.g. time 
map or (broadcast) packet order of the recording. This list Is accessible by the STB and 
the content is understood by the DVD streamer as well as by the STB. In its 'original' 
version the playlist enables the playback of a complete recording. The playlist may be 
accessed and extended after recording by the STB to allow more sophisticated playback 
sequences. 

The second piece of information, mapping list is generated to support the stream 
recorder to retrieve packet stream chunks (cells), that are described in tenns of the 
application domain (e.g. 'broadcast packets* or 'time'). This list Is owned and understood 
by the DVD streamer only. 

L 1.2.4 Content Description 

The format should reserve space, which can be used by the STB to store high level TOC 
and Service Information. This information is provided for the user to navigate through the 
content stored on disc and may contain sophisticated GUI information. The content is not 
needed to be understood by the stream recorder. However a common subset of the TOC 
information, e.g. based on a character string, may be useful to be shared between STB 
and DVD, in order to enable the stream recorder to provide a basic menu by itself. This 
may require some joint discussion with STB manufacturers, 

(Requirements for Playback) 

L L 2. 5 Playback of individual recordings 

Needs to be supported; should be possible via play list. 

1. 6 Playing all recordings sequentially 

This is basically a set matter; should be possible via playlist. 

I.i-2- 7 Player menus for entry point selection 

This is mainly STB's responsibility, which can generate a sophisticated menu based on 
the TOC information stored on the disc. However, it should be possible to generate a 
simple menu by the streamer itself, e.g. via some 'character' information which is shared 
by STB and DVD. 

LI, 2. 8 Trick play modes 

The STB should be able to steer trick play via the 'play list'. Due to the nature of the 
broadcast stream, the trick play features may be limited to basic ones, e.g. Time Search 
and Title Jump. 
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i, Z P User defined PB sequences 
Features like playback programming or parental control can be supported via the play list 

L 1,2, 10 Play list support 

The playlist must be supported as a key for all special playback and navigation. 
1, L Z 11 Play list creation 

The DVD streamer should create the 'original version' of the play list. It also should allow 
extensions and modifications of the play list by the STB for more sophisticated playback 
features. The DVD streamer is not responsible for the content of those sophisticated 
playlist(s), 

(Requirements for Editing) 



2.12 Delete single recordings 

e format must support the deletion of single recordings on user's request 



LL2.13 Delete parts of recordings 

If possible, the format should allow this feature under the control of the STB. However, 
complex processing and knowledge on the service may be required for this functionality. 

LL2,14 Inserting 

If possible, the format may support insert editing. This feature will probably require very 
complex processing and deep understanding of the service. An implementation, which will 
allow this feature, may be of semi-professional nature. 
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f.2 SystBm Model 

This specification is based on the following overall system model: 



Application 
Device 
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Figure 1-1 Overall System Model of DVD Stream Recording 
^ rpam R ata & N n vigat l on Data^ 
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1,3 Directory and Fife Structure 

The organization of Stream Data and Navigation Data of DVD Stream Recording is done 
in a specific way such as to take into account the following: 

• Any DVD Streamer Device has certain requirements to store its own ''housekeeping" 
data on the disc. These data are solely for helping the retrieval of recorded data; they 
need not be understood or even be visible to any outside Application Device. 

• Any DVD Streamer Device needs to communicate with the Application Device it is 
connected to. This communication should be straightfoPA^ard, and as universal as 
possible, so that the maximum possible range of applications - both today and future - 
can be connected to the Streamer. The Navigation Data to support such 
communication must be understandable by the Streamer as well as by the Application 
Device. 



he Streamer Device should offer to the connected Application Device a means for 
toring its own private data of any desired kind. The Streamer needs not to understand 
any of the content, internal structure, or meaning of this 'Application Private Data". 



Figure 1-2 illustrates the directory and files where all the data comprising the disc content 
according to this Specification are recorded. All the files storing the disc content are 
placed under the STRREC directory. 



Root Directory 



STRREC Directory 



COMMON.IFO 



STREAMER.IFO 



APPLICATJFO 



REALTIME.SOB 



- Other Directories 

- Other Files 



Figure 1-2 Directory and File Configuration 

Under the STRREC directory, the following files are created; 

• COMMONJFO 

Basic information to describe the stream content. Needs to be understood by the 
Application Device as well as the Streamer 

• STREAMERJFO 

Private housekeeping information specific to the Streamer Device. Needs not to be 
understood by the Application Device. 

- APPLICATJFO 

Application Private Data, i.e. information that is specific to the Application(s) connected to 
the Streamer Needs not to be understood by the Streamer 
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• REALTIME.SOB 

Recorded real-time stream data proper. 



Note that except for the files described above, the STRREC directory shall not contain any 
other files or directories. 
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2 Navigation Data Structure 

Navigation data is provided to control the recording, playing back, and editing of any 
brtstreams that are recorded according to this Specification. As sho\A^ in Fig. 2-1, 
Navigation Data consists of Stream Management Information (SMI) as contained in the 
file named COMMON. IFO and of Housekeeping Information (HKPI) as contained in the 
file named STREAMER. IFO. 

From the point of view of the Streamer Device, these two kinds of information are 
sufficient to perform all necessary operations. Their details are described in Section 
"2.1 Streamer Relevant Navigation Data" below. 




stream Manager 
Genaral Information 
(SM^GI) 



stream Title Table 
(SIT) 



Stream Playlist Table 
(SPLT) 




Housekeeping 
General Information 
(HKP_GI) 



Housekeeping Address Table 
(HAT) 



Figure 2-1 Structure of DVD Streamer Navigation Data 

In addition to these, DVD Stream Recording also foresees the possibility of reserving a 
storage location for Application Private Data (APD), which may in general also be 
^^nsldered as Navigation Data. See Section "2.2 Application Private Data" for Details. 

2,1 Streamer Relevar^t Navigation Data 

As explained above, SMI and HKPI are the Navigation Data which are directly relevant for 
the Streamer operation. 

SMI consists of three kinds of information tables, namely Stream Manager General 
Information (SM_GI). Stream Title Table (STT), and Stream Playlist Table (SPLT). These 
three tables shall all mandatorily be recorded and stored in the COMMON. IFO file in this 
order. 

HKPI consists of two kinds of information tables, namely Housekeeping General 
Information (HKP_GI) and Housekeeping Address Table (HAT). Both shall mandatorily be 
recorded and stored in the STREAMER.IFO file in this order. 

NB: Unlike in tlie "DVD Specification for Read-Only Disc Part 3 VIDEO SPECIFICATION", 
where each table within Navigation Information shall be aligned on a sector boundary, 
there is no such restriction in Stream Recording, 
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2.1.1 Stream Manager General Information (SM_G^ 



RBP 




Contents 


Number of Bytes 


Oto 9 


STRMG ID 


STRMG Identifier 


10 


10 to 11 


reserved 


reserved 


2 


12 to 15 


SMI EA 


End address of SMI 


4 


16 to 27 


reserved 


reserved 


12 


28 to 31 


SMGl EA 


End address of SM Gl 


4 


32 to 33 


VERN 


Version number of DVD Streamer 
Specifications 


2 


34 to 127 


reserved 


reserved 


94 


128 to 129 


TM ZONE 


Time Zone 


2 


130 to 191 


reserved 


reserved 


62 


192 to 195 


STT SA 


Start Address of STT 


4 


196 to 199 


SPLT SA 


Start Address of SPLT 


4 


200 to 511 


reserved 


reserved 


312 



Total 512 



(RBP O to 9) STRMGJD 

Describes "DVD_STR_MG" to identify Stream Recording Management Information File 
with character set code of IS0646 (a-characters). 

(RBP 12 to 15) SMLEA 

Describes the end address of SMI with RLBN from the first LB of this SML 
(RBP 28 to 31) SMGI_EA 

Describes the end address of SM_GI with RBN from the first byte of this SM_GI- 
(RBP 32 to 33) VERN 

Describes the version number of this Specification. 




Book Part version ... 0000b 0001b: version 0.1 

Others: reserved 

(RBP 128 to 129) TM_ZONE 

Describes the Time Zone for this Disc. All fields related to "Recorded Time" share this 
Time Zone value. The detailed structure for TM_ZONE is TBD. 

(RBP 1 92 to 1 95) STT_SA 

Describes the start address of STT with RBN from the first byte of this SM_GI. 
(RBP 196 to 199) SPLT_SA 

Describes the start address of SPLT with RBN from the first byte of this SM_GI. 
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2.1.2 Strenm Title Table (STT) 




Figure 2-2 : Stream Title Table 



2.1.2.1 Stream Title Table General Information (STT_GI) 





Contents 


Number of Bytes 


(1) ST Ns 


Number of Stream Titles 


2 


(2) STT EA 


End Address of Stream Title Table 


4 


(3) STN_CHRS 


Stream Title Name Character Set 


1 




Total 


7 



H ST_Ns 

Describes the number of Stream Titles, which are described in this STT. The maximum 
allowable number of Stream Titles is 999. 



(2) STT^EA 

Describes the End Address of Stream Title Table with RBN from the first byte of the STT. 
(1)STN_CHRS 

Identifies the character set used for the Stream Title Names (STNs) in this STT. Details 
are TBD. 



2.1.2.2 Stream Title Entry (STE) 





Contents 


Number of Bytes 


(1)AP PKT SZ 


Application Packet Size 


2 


(2)SRV ID 


Sen/ice ID 


1 


(3)AP DEV ID 


Application Device ID 


12 


(4) ST _DUR 


Stream Duration 


6 


(5) ST NM SRP 


Stream Name Search Pointer 


4 




Total 


25 




(1) AP_PKT_SZ 

Describes the Application Packet Size in bytes. TTiis packet size is valid for the entire 
stream title. 

NB: Due to the minimum transfer rate restriction rules described in Section „??", 
knowledge of the AP_PKT_SZ does not automatically and not for all streamer packets 
imply how many application packets are grouped together into the streamer packet. 

(2) SRVJD 

Describes an identifier of the digital service which created the stream of this title. Details 
of the identifier are TBD. 

(3) AP_DEVJD 

Describes an identifier of the application device that was physically delivering the stream 
of this title. Details of the identifier are TBD. 

(4) ST_DUR 

Describes the duration of the stream of this title, as resulting from the difference between 
the extended SCR of the last application packet of the stream minus the extended SCR of 
the first application packet of the stream. For the definition of Extended SCR, see 
Section „??". 

(5) ST_NM_SRP 

Describes the start address of the name string associated with this stream title, with RBN 
from the first byte of the STT. Name sharing shall not occur, i.e. each of the 
ST_NM_SRPs of the stream titles shall point to a different stream title name. 

2.1.2.3 Stream Title Name (STN) 



(1)ST_NAME 

Describes the Stream Title Name as a variable length string of characters from the 
character set identified by STN_CHRS of STT_GI. 



Contents 



Number of Bytes 



(DST NAME 



Stream Title Name 



variable 
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2-U Stream Playlist Table (SPLT) 







Figure 2-3 : Stream Playlist Table 
2.1.3.1 Stream Playlist Table General Information (SPLT^GI) 





Contents 


Number of Bytes 


(DSPL Ns 


Number of Playlists 


1 


(2)SPLT EA 


End address of SPLT 


4 


(3)SPLN CHRS 


Stream Playlist Name Character Set 


1 




Total 


6 



(1) SPL_Ns 

Describes the Number of playlists described in this SPLT. The maximum allowed number 

t playlists is 99. SPL_Ns also informs, how many SPI_SA and associated SPl are 
luded in this SPLT. 

(2) SPLT_EA 

Describes the End Address of this SPLT with RBN from the first byte of this SPLT. 

(3) SPLN_CHRS 

Identifies the character set used for the Stream Playlist Names (SPLNs) in this SPLT. 
Details are TBD. 



Z J. 3.2 Stream Playlist Search Pointer (SPJSRP) 





Contents 


Number of Bytes 


(1)SPI SA 


Start Address of Playlist Information 


4 



(1)SPLSA 

Describes the Start Address of the corresponding Stream Playlist Information, with RBN 
from the first byte of this SPLT. 
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2.i, Stream Playlist Information (SPI) 





Contents 


Number of Bytes 


(1) PE„Ns 


Number of Playlist Entries 


2 


(2) SPL CREATE TM 


Creation Time of this SPL 


5 


(3)SPL NAME 


Stream Playlist Name 


variable 



(1) PE_Ns 

Describes the Number of playlist entries of which this playlist consists. The maximum 
allowed number of playlist entries per playlist is TBD. PE_Ns also informs, which and how 
many of the subsequent PEs belong to this playlist 

(2) SPL_CREATE_TM 

Describes the creation time of this playlist in STRR's Date and Time Describing format 
TBD. 

(3) SPL_NAME 

Describes the Stream Playlist Name as a variable length string of characters from the 
character set identified by SPLN_CHRS of SPLT_GI. 



2.1,3.4 Playlist Entry Information 





Contents 


Number of Bytes 


(1)PE ST^N 


Index of Stream Title 


2 


(2)PE S SCR 


Start SCR 


6 


(3)PE E SCR 


End SCR 


6 




Total 


14 



(1) PE_ST_N 

Describes the index of the Stream Title to be played back for this PE. 

(2) PE_S_SCR 

Describes the Extended SCR value of the first application packet to be played back. 

(3) PE_e_SCR 

Describes the Extended SCR value of the last application packet to be played back. 



2.1.4 Housekeeping General Information (HIGP_GI) 





Contents 


Number of Bytes 


(DHAE Ns 


Number of Housekeeping Address Entries 


2 


(2)HKPI EA 


End address of HKPI 


4 


(3) HKP TSCAL 


Time Scale Factor 


1 




Total 


7 



(1) HAE_Ns 

Describes the number of housekeeping address entries countained in this HKPI. The 
maximum allowed number of housekeeping adress entries is TBD. 

(2) HKPI_EA 

Describes the End Address of this HKPI with RBN from the first byte of this HKPI. 



, JSi HKP_TSCAL 

"^^cribes the time scaling used within this HKPI. Details of time scaling are TBD. 
2.1.5 Housekeeping Address Table (HAT) 

The purpose of this table is to provide all necessary information so that given playlist 
entries are efficiently translated into disc address pairs (from-to). ■ Botoi l o of HAT - aro - TBD. 
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"Housekeeping" in general context of either RTRW or Stream recording is the 
task to translate a given time value (presentation time in case of RTRW, or 
packet arrival time in case of Stream recording) Into a disc address value, 
where the desired data can be found. 



Presentation data in DVD forum's AH1-5's "RTRW Specification" fs organized 
into units called "VOBU", VOBUs are variable size (data amount measured in 
number of sectors), but are also variable duration (measured in number of 
video fields). For data retrieval, i.e. for RTRW^s housekeeping, RTRW foresees 
a "VOBU map", which is a table where for every VOBU in a recording, the 
length in sectors, and the duration in fields is entered, by storing these "deltas", 
and not the total length or total duration, these entries can be described with 
smaller wordlength, which helps to keep the total VOBU map In reasonable 
size. 

In Stream recording, bitstreams have no meaning, and we are free to subdivide 
them into sub-units of more regular structure, basically, a table for data 
retrieval can be based on two principles: 

• bitstream data can be subdivided into pieces' of constant ^'duration" 
or 

• bitstream data can be subdivided into pieces of constant "length" 

in case of bitstream data subdivided into pieces of constant duration, duration 
is the difference between the arrival time of the last packet and the arrival time 
of the first packet of the piece. Then the "housekeeping address table" (HAT) 
contains a size or offset or delta size (in general, an address-like quantity) for 
each of these constant-duration pieces. The housekeeping process then 
consists of the following steps: 

• By division and truncation, calculate from the given time value the index of 
the table entry to look up. 

• The content of the table entry either directly specifies the address value to 
access, or ail table entries up to that index have to be accumulated to get 
the address value to access. 

The big disadvantage of a HAT based on constant duration pieces is the 
following fact: 

• In case of a low bitrate recording, the pieces of constant duration will be 
small in size (number of sectors). The disc can contain enormous numbers 
of those pieces, so that the HAT may become unrealistically big (tootig to be 
kept in memory). 
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• In case of high bitrate recording, the pieces of constant duration are big in 
size (number of sectors). Then, addressing one piece or another 
corresponds to a very coarse addressing on the [sector] scale, i.e. a piece 
address derived from the housekeeping can be many sectors "off" from the 
desired location. 

In summary, housekeeping based on constant-duration pieces can result in a 
too big HAT in some cases, and can result in too coarse addressing in other 
cases. 

The other alternative of housekeeping is to base it on pieces of constant size . 
This is our invention and the method that we propose in Stream recording. In a 
medium like DVD-RAM, where data are physically organized into "ECC blocks" 
of 32kByte length, additional advantages result, if this size or a multiple of it is 
used as the piece size, but in principle, any constant size can be used. 

The HAT then contains, for each of these pieces of constant size, an absoulte 
duration or (preferrably) a delta duration which indicates the arrival time 
difference between the last and first packet contained in this piece. 

The housekeeping process then consists of the following steps: 

• Accumulate the delta durations contained inthe HAT. until the given time 
value is most closely reached "from beneath" (i.e. until the sum is smaller or 
equal to the given time value for the last time). 

• The index of this table entry, multiplied by the piece size constant, directly 
gives the address value to access. 

The advantage of a constantsize-based HAT is that 

• HAT size does not depend on bitrate of the recordings. 

• HAT addressing accuracy is constant, the granularity basically corresponds 
to the "piece size constant", which can be chosen constant per disc, 
"forever", or per recording, as appropriate. 
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2.2 Application Private Data 

APD, if it exists, consists of three kinds of information, namely Application Private Data 
General Information (APD_GI). a set of one or more Application Private Data Search 
Pointer {APD_SRP), and a set of one or more Application Private Data Area (APDA). If 
any Application Private Data exists, these three kinds of information shall all mandatorily 
be recorded and stored in the APPLICAT.IFO file in this order. 

NB: Unlike in the "DVD Specification for Read-Only Disc Part 3 VIDEO SPECIFICATION", 
where each table within Navigation Information shall be aligned on a sector boundary, 
there is no such restriction in Stream Recording. 




Figure 2-2 Application Private Data 



2.2.1 Application Private Data General Information 





Contents 


Number of Bytes 


(l)APDA Ns 


Number of Application Private Data Areas 


1 


(2) APD EA 


End Address of Application Private Data 


4 


(3) APDA SRV ID 


APD Area Service ID 


APDA Nsx4 



(1) APDA_Ns 

Describes the number of Application Private Data Areas, into which this APD is organized. 

(2) APD_EA 

Describes the end address of APD with RBN from the first byte of the APD. 

(3) APDA_SRVJD 

Describes a Sen/ice ID for each of the Application Private Data Areas to follow. For 
details of Service ID, see Annex A. 



2,2.2 Application Private Data Search Pointer 





Contents 


Number of Bytes 


(1 ) APDA_SA 


Start address of APDA 


4 



(1)APDA_SA 
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Describes the start address of APDA with RBN from the first byte of APD. 





Contents 


Number of Bytes 


(DAP DA 


Application Private Data Area 


Variable 



(1) APDA 

Describes the Application Private Data. 
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3 Stream Data Format 

Stream Data according to this Specification consists of one or more .Stream Objects" 
(SOBs) which are each stored as a ^Program stream" as described in [MPEG-2 Systemsl. 
A SOB has the following restrictions; 

1. Each SOB shall be terminated by a program_end_code. 

2. The value of the SCR field in the first pack of each SOB may be non-zero. 

A SOB contains the Stream Data packed into a sequence of „Stream Packs" (S_PCKs). 
The transfer rate of SOBs shall obey the restrictions listed in Table 3-1. 
Table 3-1 : Restrictions on transfer rate of Stream Data 



Minimum Transfer rate 


TBD 


Maximum Transfer Rate 


TBD 



Stream Data described under this Specification are organized as one elementary stream 
and are carried in PES packets with a stream_ld of of private_stream_1 . In some other 
formats of the DVD family, private_stream_1 is also used to carry several kind of non- 
MPEG AV Presentation Data, As a means of distinction among these, the first byte of the 
data area of each packet is used as „sub_streamjd". DVD Stream Recording, although 
already separated by the use of a different directory for its data, shares this principle, i.e. 
the first byte of data area is used as a sub_streamjd and is entered as a new, unique 
value of TBD designating the subsequent payload as ^Stream Recording Data". 

3.i Stream Object 

A stream Object is composed of one or more Stream Packs (S_PCKs) as shown in Fig 3-1 



Stream Object (SOB) 



S_PCK 


S_PCK 


S_PCK 


S_PCK 


S_PCK 


S_PCK 



Figure 3-1 : Structure of a Stream Object 



Because the length of a SOB is basically arbitrary, the last S_PCK of a SOB might employ 
padding in one of two different ways. For details see Section ??. 

3.2 Stream Pack 

Stream Packs are „Program Stream Packs" in the sense of IMPEG2 System] and comply 
with all rules given there. The pack length is 2048 bytes (one LB) and a pack is recorded 
in one LB, 
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A Stream Pack consists of one pack header, followed by zero or one system header, and 
followed by one Stream Packet (S_PKT), An extra padding packet will not be employed, 
as shown in Figure 3-2, 









Pack 
header 


System 
header^ 


Stream Packet 


14 bytes 


^24 bytes* 





• may or may not exist 

Figure 3-2 : Structure of a Stream Pack 



A system header is included exactly in those S_PCKs, which are the first S_PCK of a 
SOB. When a system header is included, the length of the remaining Stream Pack content 
is 2010 bytes, when it is not included, the length of Stream Pack content is 2034 bytes. 



In Stream recording, the application performs its own padding, so that the pack length 
adjustment methods of DVD-ROM Video or RTRW need not to be used. In Stream 
recording it is safe to assume, that the Stream packets will always have the necessary 
length. 

3.2.1 Pack Header 



Table 3-3 : Pack header 



Field 


Number 
of bits 


Number 
of bytes 


Value 


Comment 


"^^pk.start code 


32 


4 


OOOOOIBAh 






2 


6 


provider 
defined 


01b 


SCR_base[32..301 


3 


(Note 1) 


marker bit 


1 


1 


SCR base[29..15l 


15 




marker bit 


1 


1 


SCR base[14..0l 


15 




marker bit 


1 


1 


SCR extension 


9 




marker bit 


1 


1 


program mux rate 


22 


3 


01 3883h 


mux_rate = 8Mbps (Note 2) 


marker bit 


1 


1 


marker bit 


1 


1 


reserved 


5 


1 


F8h 


11111b 


pack stuffing_length 


3 


no stuffing length = 000b 



Note 1: „SCR_base[32]" shall be set to ZERO. 
Note 2: „program_mux_rate" shall be set to 8Mbps. 
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3.2.2 System Header 
Table 3-4 : System header 



rieid 


Number 
of bits 


Number 
of bytes 


V aiuc 


Comment 


svstem header_start^code 


32 


4 


OOOOOIBBh 




header length 


16 


2 






marker_bit 


1 






1 


rate.bound 


22 


3 


809C41h 


mux rates 8Mbps 


marker_bil 


1 






1 


audio.bound 


6 




0 


No audio streams 


fixed_flag 


1 




0 


Variable bit rate 


CSPSJag 


1 




1orO^ 




^stem_audio_lock_flag 


1 


2 


1 




system_video_lock_flag 


1 




1 


1 


riarker_bit 


1 




1 1 


1 


video_bound 


5 




0 


No video streams 


packeLrate_restriction_flag 


1 


1 


Oor1 




reserved_bits 


7 




7Fh 




stream_id 


8 


1 






'11' 


2 




11b 




P-STD_buf_bound_scale 


1 


2 


1 


buf size X 1024 bytes 


P-STD_buf_size_bound 


13 




232" 


buf size = 237568 bytes 


stream id 


8 


1 






'11' 


2 




lib 




P-STD_buf_bound_scale 


1 


2 


0 


buf size X 128 bytes 


P'STD_buf_size_bound 


13 




32 


buf size = 4096 bytes 


stream_id 


8 


1 


1011 1101b 


private stream_1 


'11' 


2 




lib 




P-STD_buf_bound_scale 


1 


2 


1 


buf size X 1024 bytes 


P-STD_buf__size_bound 


13 




58 


buf size = 55392 bytes 


stream id 


8 


1 


1011 1111b 


private stream_2 


■ir 


2 




lib 




P-STD buf_bound_scale 


1 


2 


1 


buf size X 1024 bytes 


P-STD_buLsize_bound 


13 




2 


buf size = 2048 bytes 



3.3 Stream Packet 

In Stream Packets, no stuffing takes place and each Stream packet has just DTS, no PTS. 
Packet header size therefore is 14 bytes constant. 
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3.3,1 Packet Header 



Field 


of bits 


Number 
of bytes 


Value 


Comment 


pSCKGl Stan uuuts \j\ xs\ 1^ 


24 


3 


00 0001 h 




sxr earn lu 


8 


1 


1011 1101b 


private stream 1 




16 


2 






1 Lr 


2 


3 


10b 




r'to scramuriiiy LfUiiiiui 


2 




TBD 


rco priuriiy 


1 


0 


no prioritv 


aaia aiignnierii inuitr^vui 




0 


not defined by descriptor 


copyriflht 




0 


not defined by descriptor 


origindi or copy 


i 

1 


0 


copy 


r I o U 1 o TlayS 


O 


10b 




b&GR Tlao 


1 


0 


no ESCR field 


□Vrate tiag 


1 


0 


no ES rate field 


DSM tncK mode flag 


1 


0 


no trick mode field 


additional copy info_flag 


i 

I 


0 


no copy info field 


PES CRC flag 


1 


0 


no CRC field 


PES extension flag 


1 


0 


no extension 


rco neader data lengm 


Q 
O 






OOOl 




5 


Provider 
defined 




DTSr32..301 


3 




marker bit 


1 




DTS[29,.15l 


15 




marker bit 


1 




DTS[14..01 


15 




marker bit 


1 




stuffinq byte 




0to7 






Private data area 


ift) stream id | 8 1 


TBD 1 



stream data area 



3.3.2 Stream Data area 

The Stream data area inside a Stream Packet consists of an application header, an 
application header extension, and a sequence of application pacl<ets, each prefixed by an 
application packet timestamp. 
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i. J. Z i Application Header 



Field 


Number 
of bits 


Number 
of bytes 


Value 


Comment 


(DMAX BITRATE 


32 


4 






(2) SMOOTH BUF_S1Z 


16 


2 


3540 bytes 




(3)TS REF CL FREQ 


32 


4 


27 MHz 




{4)AP PKT LEN 


16 


2 






(6)TS LEN 


8 


1 


'4' 




(6)AP PKT Ns 


8 


1 






(7) START OF STR 


1 


1 


Ob or lb 




(8) END OF STR 


1 


Ob or1b 




reserved 


6 








Total 


15 







(1) MAX^BITRATE 

Describes the output bitrate parameter of the leaky bucket flow control model in Mbps. 

(2) SMOOTH_BUF_SIZ 

Describes the buffer size parameter of the leaky bucket flow control model. 

(3) TS_REF.CL_FREQ 

Describes the reference clock frequency of the packet arrival/delivery timestamp. 

(4) AP.PKT.LEN 

Describes the length of the application packet. 

(5) TS.LEN 

Describes the length of the timestamp field. 

(6) AP_PKT.Ns 

The number of application packets in this DVD pack. 

(7) START.OF_STR 

When set to '1 this packet is the first DVD pack In the stream. 

(8) END_OF_STR 

When set to '1 this packet is the last DVD pack in the stream. 
J. J. 2, 2 Application Header Extension 

The application header extension consists of a list of entries, where there is exactly one 
entry for each transport layer packet. These bytes are used to store information that may 
differ from packet to packet. 

The total length of the application header extension shall be 46 bytes. The first 
'AP_PKT_Ns' entries of these shall carry valid data. Unused list entries may carry 
undefined values. 

The total length of 'application header' and 'application header extension' shall be 61 
bytes. 
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Field 


Number 
of bits 


Number 
of bytes 


Value 


Comment 


(DAU START 


1 








(2)AU END 


1 


1 






(3) reserved 


4 








(4) COPYRIGHT 


2 









(1) AU_START 

When set to '1', indicates that the associated application packet contains a random 
access entry point into the stream 

4|^AU_END 

v^fen set to '1 ', indicates the associated application packet is the last packet of a random 
access point 

(4) COPYRIGHT 

Describes the copyright status of the associated application packet. Sctoila arc TBO 



3.3.2.3 Time Stamps 



L/s^ of Abbreviations 

LB Logical Block 

RBN Relative Byte Number 



RBP Relative Byte Position 

RLBN Relative Logical Block Number 
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Claim 



1, Method for addressing a bitstrearo to be recorded or being 
recorded on a storage medium, e.g. a DVD recorder, 
wherein an address table is used that is based on pieces 
of said bitstreaiu including a constant amount of bits, to 
each of which pieces an absolute time duration or delta 
time duration is assigned in said address table. 
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claim 



1, Method for addressing a bitstream to be recorded or being 
recorded on a storage medium, e.g. a DVD recorder, 
wherein an address table is used that is based on pieces 
of said bitstreaiu including a constant amount of bits, to 
each of which pieces an absolute time duration or delta 
time duration is assigned in said address table. 
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claim 



1, Method for addressing a bitstream to be recorded or being 
recorded on a storage raediuiri/ e.g. a DVD recorder, 
wherein an address table is used that is based on pieces 
of said bitstreaiu including a constant amount of bits, to 
each of which pieces an absolute time duration or delta 
time duration is assigned in said address taible. 
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